docs(vscode-extension): state what Export to React actually does - #8112

Fixes #7977

The page for the VS Code extension described ObjectUI: Export to React in two ways the command does not behave. Both are corrected against the command's actual product on this base, not against the card's transcript — the card predates PR #7978.

1. How the product was obtained (extracted, not transcribed)

generateReactComponent() lives in a template literal, so nothing compiles it. I read that template out of packages/vscode-extension/src/extension.ts exactly the way src/__tests__/export-to-react-preamble.test.ts reads it (locate function generateReactComponent, then the return backtick, then the closing backtick) and evaluated it with the one binding it takes, schemaJson = JSON.stringify(schema, null, 2), against the example schema this page already taught. Read-only: nothing under packages/vscode-extension/ was touched.

The docs fence is now that product byte for byte — asserted mechanically, not by eye:

FENCE_EQUALS_PRODUCT: True

Quoting the product here, with its last statement spelled in words rather than literally, because GitHub's body sanitizer eats angle-bracket-shaped tokens even inside fenced blocks:

// No React import: under the automatic JSX runtime ("jsx": "react-jsx",
// what a new Vite or Next project is configured with) nothing here reads that
// identifier, so it compiles as an unused local. Add the import back only if
// this file is built with the classic "jsx": "react" transform.
import { SchemaRenderer } from '@object-ui/react';
// Importing the package registers every default renderer as a side effect —
// there is no separate registration call.
import '@object-ui/components';

const schema = {
  "type": "div",
  "className": "p-4",
  "children": [
    {
      "type": "h1",
      "children": "Hello World"
    }
  ]
};

export default function GeneratedComponent() {
  return A SELF-CLOSING SchemaRenderer ELEMENT TAKING schema={schema};
}

2. The clipboard sentence

Before (content/docs/utilities/vscode-extension.mdx:79):

3. React component code is copied to clipboard

After — a statement of what the command does, rather than a deletion of the word clipboard:

3. The generated component opens in a new untitled editor tab, with its language set to typescriptreact
4. VS Code shows React component generated! Save it to a .tsx file. — nothing is written to disk and nothing is put on your clipboard, so save that tab yourself

That is exportToReact() at extension.ts:205-214: openTextDocument({ content, language: 'typescriptreact' }), showTextDocument, then that exact message. The identifier clipboard occurs nowhere under packages/vscode-extension/src.

3. The Output Example

Before: one import (SchemaRenderer from @object-ui/react), no semicolons, component named MyComponent, and no import '@object-ui/components';.

After: the product above. Three differences from the old example, all of them the generator's:

• import '@object-ui/components'; is present. It is load-bearing (objectui#7837: the package declares sideEffects: true, its barrel runs import './renderers', and its built dist/index.js carries 114 module-scope register( call sites) — a reader who copied the old example instead of running the command registered no renderers at all.
• The component is named GeneratedComponent, which is what the command emits.
• The schema constant is the JSON.stringify(schema, null, 2) expansion, so the nested child is on its own lines.

A short lead paragraph above the fence now says the imports are part of the output and why the side-effect import matters, so the point survives a reader who skims the code.

import React from 'react' stays absent — objectui#7862 / PR #7978 removed it deliberately, and the triage made that a hard constraint.

4. Decision asked for: the template's comments are reproduced verbatim

The ruling left this to me. I kept both comments, for two reasons: it makes the example the product byte for byte (no editorial judgement about which half of a generated file a reader gets), and the four-line comment is the page's own defence of the absent React import — the next reader or agent who thinks the example is missing an import reads the answer in place. The two-line comment is likewise the answer to "why is there a bare import here".

5. No gate

No pin, no binding of the page to the template — that is objectui#7976's class and would open a new scan population. The file surface is one content/docs page.

Gates (all on this branch's final HEAD)

Exit codes captured by redirect-then-capture, never through a pipe.

The snippet gate really judges this block — proven by ablation rather than assumed. Pointing the added import at a package that does not exist turns the gate red on this exact file and line:

[semantic]  content/docs/utilities/vscode-extension.mdx:100:8  TS2882: Cannot find module or type declarations for side-effect import of '@object-ui/components-does-not-exist'.
Semantic phase: 561 of 561 block(s) judged, 1 failed.

Restored from HEAD and proven restored by blob hash and an empty git diff HEAD.

Repo-wide pnpm lint is not owed by this diff, measured: eslint --format json on the changed path judges 1 file and reports File ignored because no matching configuration was supplied. The population is read from eslint's own configuration, the count from its JSON output; since the only changed file is outside that population, no eslint verdict anywhere can move from this change.

PM mechanism assumptions, both falsified in the helpful direction

• A1 (check:doc-snippets might refuse @object-ui/components through objectui#8059's root bound): it does not. The gate's own Root bound: line reports no refusal, and the ablation above shows the specifier genuinely resolving.
• A2 (a typescript fence might trip on JSX, needing tsx): it does not, and the fence is unchanged. check-doc-snippet-types.mjs:1433-1440 parses every block as ScriptKind.TSX regardless of the fence label, precisely because the corpus labels JSX blocks ts/tsx/typescript interchangeably.

Live E2E (informational) is red on every branch today for an upstream reason (#7990) and is not from this change.

Generated by Claude Code